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The current computer programmings encapsulate attributes and behaviours 
into objects, but miss the mechanism to support the connection among objects. 

A programming paradigm is presented to connect all objects. The connection 
supports communications. Protocols are defined to coordinate the behaviours 
between objects, which enable the interaction of objects across different plat¬ 
forms. The connection also provides an efficient mechanism to support the 
concurrency, parallelism, distribution, pipeline and adaptability, etc. They 
can be governed transparently, autonomously, even adaptively. In this paper, 
an implementation is also discussed to show the effectiveness of protocol pro¬ 
gramming. 

Connection is the norm 

The connection between entities is an important aspect of the world. Large objects as celestial 
bodies or small objects as biomolecules are connected, by gravity or conjugation, and organized 
into a galaxy or an organism. The connection should not be treated as an attribute of an object. 
It has a powerful influence on the connected objects. For example, gravity controls trajectories 
of celestial bodies, chemical reactions determine the transformation between substances. And 
relations, e.g., food chain, heredity, etc. judge the fittest and influence the evolution of species. 
The connection condenses substances into the cosmos, synthesizes amino acid and brings the 
life. All things are influenced or developed by connecting with others. 
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In this article, we define “connection” as the channel for interactions between objects. Usu¬ 
ally interactions are not random, they show a clear pattern. The patterned interaction is referred 
to as “communication” in this paper. The connection supports communications between ob¬ 
jects. It is the core idea of our method, we give an example for easier understanding. Let’s 
consider the ocean, the land and the sky as a platform for the the biological world. Animals 
wander around the platform. It should be emphasized that the ability for an animal to ramble 
is important, referred to as “autonomy”. It enables animals to change to fit its surroundings. 
Strolling animals are connected by inhabiting or encountering with each others. In the wild, 
passing each other does nothing about the communication. The communication between them 
is established by giving birth to, feeding, preying, fighting, etc. 

In the digital world, to imitate or encode a system under a programming paradigm, the mod¬ 
ularity is an important issue, which supports structured programming. Modules (e.g., classes 
or functions ( 1 , 2)) are used to encapsulate objects and partition a system into different parts. 
However, in practice, it is common that a complex problem can not be perfectly partitioned. For 
example, to design a building, some parts of a building (e.g., the water supply or power system) 
are difficult to be encapsulated. This is also known as the crosscutting issue (2). It makes the 
code tangled and increases the cost of communication among developers when designing and 
developing a system (4). Furthermore, in object-oriented programming, an object is merely 
nested in another object as a member variable. The inner object is restricted by the holder that 
difficult to be shared with others. It also sacrifices the autonomy of an object, making it difficult 
to update independently. 

Without a mechanism to support the connection appropriately, a hard partition hurts the 
communications between objects. In the traditional programming paradigms, various approaches 
are applied to support communications between objects. For example, objects can be used as 
function parameters or member variables of other objects. Inheritance is used to represent re¬ 
lations between classes. It does nothing about the communication unless static members are 
defined in the declaration (5). Then instantiated objects can share the same variables for com¬ 
munications. Others such as message passing, semaphore, shared memory, socket, etc. are 
widely adopted to support communication. Because the lack of the connection between objects, 
these approaches are used to support the communication weakened by separating a system into 
discrete parts. Traditionally, the connection as a mechanism to support communications has re¬ 
ceived less attention. The communications between objects are temporary and irregular, mainly 
used to exchange data or control resource competition if required. It is rarely formalized as a 


2 



connection mechanism to support communications. 

Compared to the traditional paradigms, connection in protocol programming is developed 
into a new territory. Under the protocol programming, programming is divided into two steps: 
protocol implementation and domain implementation. Protocol implementation builds an in¬ 
frastructure to support the communication between objects. Protocols are defined to control 
the communication between them. By inheritance from a protocol implementation all instanti¬ 
ated objects are automatically connected into a network. Domain implementation is developed 
by traditional programming paradigms, encapsulating attributes and behaviours into objects. 
While supported by protocol implementation, partitioning a system into discrete models and 
reorganizing them become easier and more effective. 

Connection creates possible 

Building a system is usually not a trivial matter. It is often partitioned into discrete modules 
(e.g., procedures, functions, objects, agents, aspect, etc.), then a team is set up to implement 
each module separately. It is generally accepted that a modular design is the key to successful 
programming. All programming paradigms have mechanisms to support structured program¬ 
ming, where the modularity is guaranteed. Systems developed by structured programming have 
good stability, efficiency, maintainability and expansibility. The main obstacle for structured 
programming is that some problems are difficult to be partitioned. In some projects, design 
decision is scattered throughout a system. A hard partition breaks the connections between 
modules and hurts the communications between them. 

In the digital world, to support the partition and connection between modules, many pro¬ 
gram paradigms are developed, e.g., agent-oriented programming ( 6 ), aspect-oriented program¬ 
ming (7). Based on message passing, mechanisms are proposed for communicating between 
threads or processes (e.g., Message Passing Interface (8), Erlang (9), Hoare et al. ( 10 )). The 
communication across different systems are also designed (e.g., MapReduce ( 11 ), service- 
oriented computing ( 12 ), CORBA ( 13 )). In a program, mechanisms (e.g., semaphore, shared 
memory, socket, message passing) are used to support the communication between partitioned 
modules. Because implementation of these mechanisms is not transparent to programmers, 
it may lead to many issues such as mutual exclusion, interrupts, data conflict, resource com¬ 
petition, etc. When building a system, these mechanisms increase the burden of design and 
implementation, and make the code difficult to understand and maintain. Furthermore, when a 
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system is complex enough, partitioning it, defining the interfaces and integrating every part are 
very challenging. The cost to design, develop and maintain such a system and the communica¬ 
tion between developers are increased considerably (4). 

To better illustrate our ideas, we analyse two systems (the Internet and the biosphere), which 
show the motivation of protocol programming. 

Since the invention of packet switching theory (14), for half a century, the Internet has ex¬ 
panded into a huge system with billions of access points and numerous applications (15). At 
the dawn of computer communication (16), it is difficult to foresee that human society can build 
such a complex system. Despite various techniques are developed to accelerate the growth of the 
Internet, the most important technique is the Internet protocol deigned for the open-architecture 
network environment. Under the internet protocols, every equipment is independently con¬ 
nected into the Internet and the information between them are routed automatically. The In¬ 
ternet protocol hides the underneath implementation of connected modules. By following the 
Internet protocol, each part of the Internet can conveniently interact with each other across het¬ 
erogeneous platforms or systems. Moreover, because the Internet protocol is a connectionless 
service, each part can be updated independently. 

The biosphere is a largely self-regulated system. The earth can be seen as a platform for life 
to compete. Individual organisms of the earth encounter on the land, in the air or the water. The 
connection (encounter) is an important aspect for life on the earth. After the connection was 
constructed, the interaction between them is not random. They follow inherent patterns (e.g., 
foster, prey, competition, hereditary and variation) in the same way as the protocol. Life in the 
biosphere is ruled by these patterns, referred to as laws in biology. Hereditary and variation are 
two important laws determining the survival of a species and the evolution of the living nature. 
Many factors can disturb the natural stability of the biosphere, e.g., the geographical or climatic 
factor, the species diversity and the food chain, etc. They are the motive force for the species 
variation. The variation enables that a species can adapt to the environmental change, “survival 
of the fittest” ensures that the suitable change is inherited. Accumulated changes in individuals 
or species give rise to the evolution of the species. 

Designing or constructing a system like the Internet or the biosphere in one step is far beyond 
human ability. They are not built, but evolved. Five characteristics can be induced from such 
systems. Each system should consist of modules or individuals that are mutually independent, 
which enables the separableness. Individuals can interact with each other and the connection 
is guaranteed. The interactions between individuals are not random, they follow predefined 
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or evolved patterns. Then the communication between them is established. For a system that 
supports evolution, individuals have the ability to change, which enables the fittest is reserved, 
and the adaptability is possible. 

A system is a set of interdependent and interacting modules (components or individuals), 
which forms an integrated whole. If partitioned modules are unrelated, the system is static and 
inactive, shows no interaction. In a dynamic, autonomous or adaptive system, the interconnec¬ 
tivity between modules is required. The separableness ensures that a system can be partitioned 
into modules, so each module can be designed or developed independently. It is the premise 
for concurrency, parallelism and distribution. Modules of a system can be connected by struc¬ 
tural, functional, behavioural relationships. The connection bands partitioned modules together. 
Then the interaction between modules would occur frequently. Many interactions are not ran¬ 
dom. They will show some kind of patterns (e.g., protocols and laws in the Internet and the 
biosphere). These patterns are the manufactured products of the communication, which makes 
them coordinate, compete, develop and struggle for existence. The connection supports com¬ 
munications. In traditional paradigms of the digital world, the communication is supported by 
limited approaches, e.g., semaphore, shared memory. They are mainly designed for exchanging 
data between partitioned modules in a system. No valid channel is provided for every object 
that they can communicate without any constraints. 

Motivated by issues discussed above, a protocol programming paradigm is presented for 
designing and implementing a system. Protocols are predefined communicating patterns. They 
are used to connect and coordinate each module in a system. In this paradigm, programming is 
divided into two aspects: protocol implementation and domain implementation. Protocol im¬ 
plementation provides a platform for connecting or coordinating instantiated objects. Domain 
implementation can use the traditional methods to encapsulate objects. But supported by a pro¬ 
tocol implementation, when designing and encoding a system, the development process become 
simple. Because the communication can be designed to be connectionless, modules can have 
the ability to update itself without stopping the system. 

In order to show the methodology of protocol programming, next, we give a simple discus¬ 
sion about the implementation developed in our work. 
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Protocol Implementation 


Our protocol implementation has two layers: transmission layer and sendee layer. The trans¬ 
mission layer supports the connection, providing a channel for communication. In this layer, a 
protocol is designed to establish a thread network, referred to as the connecting network. The 
service layer supports the connected objects to register, require and execute a service according 
to a defined protocol. The framework about the programming paradigm is shown in Figure [0 
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Figure 1: Protocol Programming Architecture 


The protocol implementation is divided into different layers. Each layer is implemented by 
a class. If a class implements a non-bottom layer, this class should inherit from a parent class 
that implements a lower layer. It is better that each layer is designed to be transparent, only the 
interface is known by the upper layer the same as the OSI model (77). Every object instanti¬ 
ated from the transmission layer is connected into the connecting network, where all messages 
between objects are transmitted automatically. In the service layer, the service configuration, 
registration, request and execution are performed. In the domain layer, each object implements 
specific work. Next, the paradigm is discussed. 

In the protocol implementation, the connection and communication are done by transmitting 
messages from one thread to another. Unlike transmitting an IP package through the Internet, 
in a local environment, all messages share the same memory space. Therefore, only the address 
of message is posted between threads. The structure of a message is given as follows, where 
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PMessage is a class. Every message is an instantiation of this class or its sub-class. 


PMessage{ 

LAYER m-Layer ; 

ACTION m-Action ; 

ADD m-Intend] 

ADD mJCreator ; 
bool rri-NeedEchoFlag ; 
size_t rri-TimeT oLive ; 

TIME rri-CreateTime ; 
vector(ADD) ni-Route-v; 
vector(string) ni-Param-v ;} 

The LAYER and ACTION are enumerated data types. The field m.-Layer is used to indicate 
which layer a message should be delivered for further processing. Three types are defined, rep¬ 
resenting each layer respectively. Each layer supports a certain numbers of actions suggested 
in the field ni-Action. The ADD represents the address (or identification) of an object. The 
fields m-Intend, and m-Creator are the destination and creator of a message. In the field 
rri-NeedEchoFlag , a true value indicates that a response is required by mJCreator. The 
m-TimeToLive is a hop count used to limit a message’s lifetime. The m-CreateTime can 
be used to line up arrived messages for avoiding problems such as data access violation when 
accessing a critical resource. When a message is transmitted through the network, the field 
nri-Route-V can be used to record the route information. The field rri-Param-V stores parame¬ 
ters of message. 

Transmission Layer 

The main purpose of the transmission layer is to build an infrastructure for message trans¬ 
mission. We design a class named as PTrans to do this. Three threads are created in each 
instantiated object of PTrans: configuring thread, connecting thread and acting thread, used for 
configuration, connection and action respectively. They run concurrently.Five kinds of actions 
are defined in the transmission layer: CONFIG, HELLO, ECHO, TICK and EXIT. 

All messages are posted through the connecting thread. A connecting thread retrieves mes¬ 
sages from its message queue. If a message’s destination matches itself, the message is taken 
off. Otherwise, it is retransmitted according to a routing protocol. Because other messages in 
its message queue may be waiting for transmitting, it is not reasonable to spend too much time 
for processing a message in the connecting thread. The connecting thread pushes its message 
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into a transmitting message list and return immediately. All messages in the list are processed 
by the acting thread. If the message list is empty, the acting thread is blocked. If a message is 
added, the connecting thread sets a semaphore. Then the acting thread is waken up to process 
the arrived message. 

In protocol programming, the most important problem is how to make every object con¬ 
nected. The topology of connecting network determines the strategy to establish it. In our 
implementation, we design a tree structure. The object in the structure also is referred to as 
node. The Master is the root of the structure and a leaf node is an object without any child. In 
our implementation, every object is identified by the connecting thread handle. The child object 
(the child) is used as a member variable of a parent object (the parent). The child has its parent’s 
connecting handle as a parameter for initialization. Then, after all objects are initialized, except 
the root object, every object knows its parent’s connecting handle. 

After a child is initialized, using parent’s connecting handle, the child reports its connecting 
handle to its parent by posting a CONFIG message, then waits for a response. The parent 
collects the child’s identification from the message and posts a message in return. After this 
process, each pair of parent and child know the connecting threads between each other. All 
configuring threads exist except that in the Master, which will be running until the system 
terminates. 

The configuring thread in Master broadcasts a HELLO message to all its children to start a 
connecting process. The Master will wait until all responses of its children are returned. After 
a HELLO is received from its parent, every object also broadcasts a HELLO to its children. 
It responds an ECHO to its parent in two conditions: all feedbacks from children are returned 
or it has not child at all. In a concurrent environment, some threads may be blocked or sus¬ 
pended, if a time-out error occurs,, the Master can restart a new connecting process. When 
children’s ECHO arrive at the Master, it means that every object is instantiated successfully. 
A connecting tree structure is established. 

All messages are transmitted in the connecting network. If there is no message to process, a 
connecting thread is blocked by calling a GetMessage(&msg, ...) function. A blocked connect¬ 
ing thread is aroused by arrived messages. Because all threads are running concurrently that 
some threads may be jammed or blocked, the TICK message is used to check the state of an 
object. The EXIT is used for system to exit. Every node retransmits this message to its children. 
All nodes from the leaves to the root will release its resources and send a response to its parent. 

It the arrived message does not belong to the transmission layer, the acting thread calls a 
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pure virtual function Trans-Outlet to process it. 


Interface 

The connecting thread and the TransjOutlet are the interface between the transmission layer 
and the service layer. In the service layer, a requirement is submitted by using the handle as 
parameter to post messages, and the Trans-Outlet is overridden to provide services. 

Service Layer 

In this paper, a domain service (or a service for short) is defined as a function that can be 
executed to support a request in an application. It is provided in the domain layer. The service 
layer doesn’t provide any domain service. The major function of the service layer is to supervise 
the services provided in the domain layer. 

The service layer is implemented by a PService class inherited from the PTrans. The pure 
virtual function Trans-Outlet in transmission layer is overridden in the PService class. Be¬ 
cause the PTrans is inherited, any object instantiated from the PService class is automatically 
connected into the connecting network. If a matched message cannot be processed in the trans¬ 
mission layer, the function Trans-Outlet will be called. Three actions are defined in the service 
layer: REG, REQ and ACK. 

Because the implementation of service layer is transparent and independent from the domain 
service. Therefore, the service layer should be given the information about a domain service. 
A PServicedepict class is defined to contain this information, named as the service descrip¬ 
tion. Each service must have a service description. The content of the service description is 
introduced next. 

The service register is started by the Master through broadcasting a REG message to its 
children. The REG message is spread from the root node to all leaf nodes. Every node collects 
service descriptions from its children and reports all services it knows to its parent. When the 
service description transmits through the connecting network, routing information is collected. 
With this protocol, every object contains service descriptions about it and its children. The 
Master knows the all services in a system. 

If a service is requested by an object, it is done by packaging a REQ message into the 
connecting network, where the name of the service and possible parameters are filled. In our 
implementation, a string matching strategy is used to match a service. When requesting a 
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service, the synchronization and asynchronization should be considered. In asynchronously 
calling, the object keeps going after a requirement was posted. Otherwise, it is blocked to wait 
an ACK message. The message is packaged by calling a requesting function defined in the 
PService class, then transmitted from the requesting object towards the Master. If an object 
has a service description matching this requirement, the message is retransmitted to the provider 
directly by routing information in the service description. 

If a REQ message arrives at its provider, the message is appended into a local message 
list of the PService class, named as the service message list. An executing thread defined in 
the class is always waiting for processing each message respectively. Two approaches can be 
used to implement a service: a thread or a function. Their addresses are stored in the service 
description. In the service description, two fields are declared to indicate which approach is 
supported and whether or not the service is reenterable. 

Many mechanisms can be designed to support the execution of a service. For example, for 
a specific service, if the service is executed by a thread, then the service message can be posted 
into the thread directly. If a service is declared in a class in the domain layer, then for each 
arrived message, a new object of the class can be instantiated to handle this service. If the codes 
are reenterable, it is possible to create a new thread to process each message separately and 
concurrently. Furthermore, the dynamic scheduling can be designed to support the load bal¬ 
ancing. These mechanisms are automatically supervised in the service layer. Only the service 
descriptions are shared between the service layer and the domain layer. 

After a REQ message is executed, if a response is required in the synchronously calling, it 
will return an ACK message. 

Interface 

One interface of the service layer is the requesting function, where the REQ message is gener¬ 
ated and posted into the connecting network. Another interface is a service description list. It is 
a member variable of the PService class used by the domain layer to report its services. 

Domain Implementation 

In domain implementation, the traditional programming methods can be used to provide the 
domain services. However, by inheriting a protocol implementation, all instantiated objects are 
connected into the connecting network. Every connected object can communicate with each 
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other by predefined protocols. Therefore, the difficulty to partition a problem into discrete tasks 
is reduced. Following the predefined protocol, every module can be developed independently. 
Because the concurrency, distribution, or load balancing, etc. can be supported transparently by 
the protocol implementation, it also reduces the burden to develop the domain implementation. 


Evaluation 


Three classes, inherited from the PService, are declared in the domain layer. Each provides 
a toy service, named as Service 1, Service 2 and Serviced). They separately execute 1 x 10 6 , 
2 x 10 6 and 1 x 10 6 Floating Multiply Instructions (FMI). Three objects are instantiated from 
each class respectively. They are connected into a connecting network with a Master object 
instantiated from the PService class. 

In the first experiment, the monotone model runs every service in a single function without 
transmitting message. In the sequence model, the Master orderly executes each service by 
synchronously posting the REQ message to the three objects. In the pipeline model, the objects 
are organized in a line and asynchronously called from one to another. They are executed 
simultaneously. Because the computation complexity of the Service 2 is doubled, it becomes 
the bottleneck in the pipeline model. In the super pipeline, two objects are instantiated to 
provide the Service 2 service. Running timeQof the four models is shown in Figure |2(aj| 
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Figure 2: Evaluation of Protocol Programming 


In Figure [2(aj| the performance of the monotone model can be seen as a benchmark. In the 
'The evaluation uses a Window 7 OS with Intel i5-2400 3.10GHz 4 Core CPU and a 8 GB memory. 
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sequence model, because synchronously calling is used, the time consuming is increased due to 
message transmitting. In the pipeline model, the expense caused by transmitting messages can 
be offset by allowing the services to be processed simultaneously. The super pipeline has a load 
balancing mechanism, therefore, the highest performance is received. 

In Figure |2(b)[ the speedup^ of the super pipeline model is compared using different num¬ 
bers of FMI. When the number of FMI is decreased exponentially in each service, the speedup 
is decreased accordingly. When the number of FMI is decreased to 10 3 , the cost of transmitting 
message negated the superiority of the super pipeline. Therefore, the speedup is less than 1. 

The implementation has a very high speedup, because, instead of a single thread, multi 
threads are used to implement the services. The main advantage of protocol programming is 
that the concurrency is managed automatically by the protocol implementation. 

Discussion 

In protocol programming, three types of objects exist: the Master object, the Server object 
and the Router object. The Master is designed for governing a system. It is also helpful to 
use multi-master objects in a system. Each performs a specific assignment. The Server refers 
to the object who provides the service. A Router is a node, which only transmits messages and 
no service or management is assigned. It can can be used to organize a system or partition the 
message space. In a system, mixed objects can be used. 

After a system is initialized, every object inherited from the PService class will have at 
least three threads. All communications between them are performed by message transmitting. 
Therefore, the concurrency is naturally supported. When a system is running, objects can be 
added or erased from the connecting network dynamically, which can be used to support the 
dynamic scheduling and the load balancing. 

Because the connecting network provides a connectionless service to all objects, the service 
provided by the program can be updated without stopping the system. Other methods devel¬ 
oped in the Internet protocol can be introduced for the protocol implementation, e.g., domain 
name service, error control, structured naming strategy, etc. In addition to keeping the program 
and the service description locally, Both can be registered and stored in a remote server, then 
accessed though the Internet. If a service is supported in a remote system, the message can be 
transmitted across the Internet and executed in the remote system. If possible, the program can 

2 It is computed by dividing the time consuming in the monotone model and the super pipeline model. 
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also be downloaded directly and run locally. 

In summary, the advantages of the protocol programming include: (a) a novel paradigm for 
programming is presented, which divides the process into two aspects: protocol implementation 
and domain implementation, (b) the connection as a mechanism to support communication for 
programming is emphasized and developed, (c) protocols are designed to control the commu¬ 
nication between objects, which enables the communications across heterogeneous programs, 
systems and the Internet, (d) Because one protocol implementation can be shared by different 
applications, it ensures a broad range of code reuse, (e) mechanism such as concurrency, paral¬ 
lelism, distribution, pipeline and adaptability, etc. can be governed transparently, autonomously, 
even adaptively, (g) it supports the autonomy of objects, which enables an object to update itself 
when the system is running. 
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